Transmission of packet data over a network with a security protocol

ABSTRACT

A method, device, system and computer program for providing a transport distribution scheme for a security protocol are disclosed. A first packet data connection is established to a remote node for transmitting packet data over a network with a security protocol. An authentication procedure is performed with the remote node via the first packet data connection for establishing a security protocol session with the remote node. At least one security parameter is negotiated with the remote node for transmitting packets through the first packet data connection. A second packet data connection is established to the remote node, and at least one security parameter is negotiated with the remote node for use with the second packet data connection. The first and second packet data connections are handled as packet data subconnections associated with the security protocol session.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of priority from FinnishPatent Application No. FI 20050769, filed Jul. 19, 2005, the entirecontents of which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to transmission of packet data over anetwork. In particular the present invention relates to transmission ofpacket data over a network with a security protocol.

2. Description of the Related Art

Data transmission over packet data networks, in particularly overInternet Protocol (IP) based networks, is very common nowadays. Thereare, however, risks in using the Internet or other public data networksfor communications. IP-based networks face threats such as viruses,malicious crackers and eavesdroppers.

Virus-scanning software and firewalls are widely used to preventunauthorized access to internal networks from public networks. Whenconfidential data is transmitted over a public packet data network, thedata should be encrypted and the sender and receiver of the data shouldbe authenticated. The security concerns relating to data transmissionover public networks can be addressed in a variety of ways. One exampleis the use of the Internet Security protocol (IPSec) on the IP level.Another example is the use of a security protocol above the IP level.

The Secure Shell protocol is a security protocol that is typically usedover the Transfer Control Protocol (TCP) and the Internet Protocol. Inprinciple, the Secure Shell can be used above any protocol providingreliable data streams. A protocol proving reliable data streams refershere to a protocol ensuring that in normal situations a receiverreceives data packets in the sending order and all sent data packets arereceived. The Secure Shell protocol provides encryption and integrity ofdata and authentication of the sender and receiver of data.

The Secure Shell protocol is in the following used as an example of asecurity protocol. The Secure Shell is being standardized in the SecShWorking Group of the Internet Engineering Task Force. The Secure Shellprotocol is a packet protocol, and the protocol packets containinformation about the length of the protocol packet and about paddinglength. The Secure Shell protocol packet then contains the actualpayload and the padding data.

A Secure Shell protocol session between two endpoints is typicallyestablished in the following manner. First, a TCP connection isestablished between the endpoints for an initial key exchange.Thereafter the endpoints authenticate each other and agree on varioussecurity parameters by transmitting protocol messages over the TCPconnection. After a successful authentication and security parameternegotiation, the negotiated security parameters define encryption anddata integrity algorithms that are used for Secure Shell protocolpackets transmitted over the TCP connection. Some further transmissionparameters, for example data compression algorithms, may be defined forthe data to be transmitted over the TCP connection.

There may be a plurality of channels within a single Secure Shellsession. These channels share the authentication and negotiated securityparameters, and data relating to all channels is transmitted over theTCP connection established for the Secure Shell session. New channelsmay be opened and existing channels may be closed during a Secure Shellsession.

When the TCP connection carrying the Secure Shell protocol packets isslow or the TCP connection goes via overloaded networks, the throughputof the Secure Shell protocol is quite low. For some reason, thethroughput is lower than what could be expected simply based on thethroughput of the underlying TCP connection. Furthermore, if some TCPpackets carrying Secure Shell protocol packets are lost and need to beretransmitted, it takes a while before the Secure Shell protocolrecovers. This is at least partly due to the fact that the flow controlof the Secure Shell is disturbed and the data buffers of the SecureShell session may be filled. A further problem is that in an overloadednetwork, a TCP connection used by the Secure Shell protocol may beslower than TCP connection on the average.

Furthermore, data that is transmitted between the endpoints of a SecureShell session may contains packet data relating to various applications,which have different security requirements. For example, packet data fora video player could suffice with a light encryption, whereas text filesto be transmitted should be secured with a stronger encryption. It maybe quite difficult to find encryption parameters to provide a suitablecompromise. One option to overcome this problem is to open a pluralityof Secure Shell protocol connections between the endpoints and to selectthe security parameters for the separate Secure Shell protocolconnections to meet the requirements of the different applications, butthis requires further memory and other resources in the endpoints.

There are thus various problems relating to providing a Secure Shellsession over a TCP connection or other reliable packet data protocolconnection. It is appreciated that although above reference is mademainly to the Secure Shell protocol, the problems may be relevant alsofor other security protocols.

Embodiments of the present invention aim to provide method fortransmitting data over a network with a security protocol in a flexiblemanner.

SUMMARY OF THE INVENTION

In accordance with an embodiment, there is provided a method fortransmitting packet data over a network with a security protocol. In themethod a first packet data connection is first established to a remotenode, whereafter an authentication procedure is performed with theremote node via the first packet data connection for establishing asecurity protocol session with the remote node. At least one securityparameter is then negotiated with the remote node for transmittingpackets through the first packet data connection. A second packet dataconnection is also established to the remote node, and at least onesecurity parameter is negotiated with the remote node for use with thesecond packet data connection. The first and second packet dataconnections are handled as packet data subconnections associated withthe security protocol session.

In accordance with another embodiment, there is provided a communicationsystem that is configured to establish a first packet data connection toa remote node and to perform an authentication procedure with the remotenode via the first packet data connection for establishing a securityprotocol session, and wherein at least one security parameter isnegotiated with the remote node for transmitting packets through thefirst packet data connection. The system is further configured forestablishing a second packet data connection to the remote node and fornegotiating at least one security parameter with the remote node for usewith the second packet data connection. In the system the first andsecond packet data connections arte handled as packet datasubconnections of the security protocol session.

In accordance with a further embodiment, there is provided a device foruse in a communication system. The device is configured for establishinga first packet data connection to a remote node, for performing anauthentication procedure with the remote node via the first packet dataconnection for establishing a security protocol session, and fornegotiating at least one security parameter with the remote node fortransmitting packets through the first packet data connection. Thedevice is further configured for establishing a second packet dataconnection to the remote node and for negotiating at least one securityparameter with the remote node for use with the second packet dataconnection. The devices handles the first and second packet dataconnections as packet data subconnections of the security protocolsession.

Furthermore, there is provided a computer program with program codemeans to carry out the steps of a method in accordance with an aspect ofthe invention. The computer program can be executed in a computer or ina set of computers.

BRIEF DESCIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described by way ofexample only with reference to the accompanying drawings, in which:

FIG. 1 a shows schematically, as an example, a communication network andtwo nodes, where embodiments of the present invention are applicable;

FIG. 1 b shows schematically, as an example, a security protocolconnection between two nodes in accordance with an embodiment of thepresent invention;

FIG. 2 a shows, as an example, a block diagram of a security protocolentity in accordance with an embodiment of the present invention;

FIG. 2 b shows, as an example, a further block diagram of a securityprotocol entity in accordance with an embodiment of the presentinvention;

FIG. 3 a shows, as a first example, a partial flowchart relating toselection of packet data subconnections;

FIG. 3 b shows, as a second example, a partial flowchart relating to analternative selection of packet data subconnections;

FIG. 3 c shows, as a third example, a partial flowchart relating to afurther alternative selection of packet data subconnections;

FIG. 4 shows, as an example, a flowchart of a method for setting up asecurity protocol connection in accordance with an embodiment of theinvention;

FIG. 5 shows, as an example, a flowchart relating to a protocolextension mechanism for the Secure Shell protocol; and

FIG. 6 shows, as an example, a flowchart of a method for providingdistributed transport for the Secure Shell protocol in accordance withan embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

In the following, embodiments of the invention are often discussed indetail with reference to the Secure Shell protocol, but it isappreciated that embodiments of the invention may be applicable inconnection with any security protocol using a reliable data transportprotocol.

FIG. 1 a shows schematically a communication network and two nodes 10,20 communicating via the communication network, for example via theInternet. The communication network may include various subnetworks, asshown in FIG. 1 a. A security protocol is used to provide secure datatransport between the nodes 10 and 20 over the communication network.One of the nodes is typically a server and the other node is a client.The client contacts the server for forming a secure connection betweenthe nodes.

FIG. 1 b shows schematically, as an example, a security protocol session(or a security-protocol connection) 30 between two nodes 10, 20 inaccordance with an embodiment of the present invention. Each of the twonodes 10, 20 has a security protocol entity 12, 22 providing thefunctionality of the security protocol. The security protocol entity isa computer program or part of a computer program. The security protocolsession 30 is a logical connection between security protocol entities.

The data transfer for the security protocol entities 12, 22 is providedby transport protocol entities 14, 24. FIG. 1 b shows a plurality ofpacket data connections 32 between the transport protocol entities 14,24. This plurality of packet data connections forms a set of packet datasubconnections of the security protocol session. In a specificembodiment of the invention, the security protocol is the Secure Shellprotocol and the transport protocol is the Transfer Control Protocol(TCP). As discussed above, in principle the invention is applicable toany security protocol used on top of any reliable data transportprotocol. If the security protocol does not rely on support of areliable transport protocol, any transport protocol may be applicable.

In the following description, the term “packet data subconnection”refers to a packet data connection belonging to a set of packet dataconnections associated with a security protocol session. From the viewof the security protocol session, there is thus either one packet dataconnection or a plurality of packet data subconnections associated withthe security protocol session. It is appreciated that from the point ofview of the transport protocol, a packet data subconnection of thesecurity protocol session is typically similar to any packet dataconnection of the transport protocol.

It is evident to a skilled person that the packet data connections 32 ofthe transport protocol are implemented using further protocol entities,such as Internet Protocol entities. The details of the lower protocolsand the physical medium between the nodes 10, 20 are irrelevant for thepresent invention, and they are therefore not discussed in detail inthis connection.

FIG. 2 a shows, as an example, a block diagram of a security protocolentity 12 in accordance with an embodiment of the present invention.More specifically, FIG. 2 a shows features relating to sending ofinformation. The security protocol entity 12 typically maintainsinformation about the packet data subconnections 32 relating to thesecurity protocol session. In FIG. 2 a, the information is shows as atable 200. The table 200 lists the available packet data subconnections.For each packet data subconnection, security parameters are typicallylisted. FIG. 2 a shows, as an example, the following security parametersfor connection 1: encryption algorithm, encryption key, integrity checkalgorithm, and integrity check key. Additionally, information aboutcompression mode is stored for the connections. Also otherconnection-specific information could be listed in table 200. Typicallyat least parameter relating to encryption and integrity check algorithmsand relating keys are among the security parameters. Any suitableencryption and data integrity algorithms may be used in connection withthe present invention.

The security parameters of the packet data subconnections are typicallydecided when the packet data connections are established, andinformation is stored in the table 200 accordingly. It is possible thatmore than one packet data subconnection has identical securityparameters. This way data can be distributed over a plurality oftransport connections in the data transport level, but on the securityprotocol level the encryption/integrity checks/compression is the same.Distribution of security protocol packets over packet datasubconnections having identical security parameters provides theadvantage of distribution data over parallel connections. For example,if one of the packet data connections is slower than others temporarily,the other packet data connections may be used. Alternatively, eachpacket data subconnection may be used in turn (Round-Robin) fortransferring security protocol packets. Alternatively, each packet datasubconnection may have specific security parameters and a packet dataconnection is chosen based on the security needs of the data to betransmitted. A further alternative is to have groups of packet dataconnections, connection within each group having identical securityparameters and the security parameters varying from group to group.Encryption and/or integrity check keys are typically different for thepacket data subconnections.

It may be possible to change the security parameters of the packet datasubconnections during the security protocol session and to updateinformation stored in the table 200 accordingly. Alternatively oradditionally, it may possible to close a packet data subconnectionhaving security parameters no longer needed and to open a new packetdata subconnection with new security parameters.

In block 201, a piece of data to be secured is received in the securityprotocol entity 12. This piece of data can be obtained, for example,from a specific application forwarding the data specifically to thesecurity protocol entity 12. As a further example, there may be definedthat certain data to a given destination needs to be secured. Thesecurity protocol entity 12 may in this case be configured to monitordata to be sent and capture data that needs to be secured.

Block 202 is responsible for forming a security protocol packet (or aplurality of security protocol packets) containing the received piece ofdata. The received piece of data is thus embedded in the securityprotocol packet(s). The formed security protocol packets usually containsome order information, typically sequence numbers, for enabling thereceiving security protocol entity to process the security protocolpackets received over a plurality of transport connections in a correctorder. As a further example, time stamp information may be used as orderinformation. The order information may be omitted, if the receptionorder of security protocol packets is irrelevant and/or the securityprotocol does not employ the concept of a security protocol packet flow.

In block 203, information about the embedded data, which is relevant forselection of a subconnection, may be tagged. This tagging may be done byplacing flags to the data structure corresponding to the securityprotocol packet or by storing information about the embedded data to aseparate data structure. As this information about the embedded data isrelevant for the selection of the subconnection, it is typically notsent to the receiver of the security protocol packet. This informationabout the embedded data is typically used only by the sender of theprotocol packet.

In block 204, a packet data subconnection is selected for the securityprotocol packet (optionally based on the data embedded in the securityprotocol packet). The data embedded in the security protocol packet isprotected also in block 204. Information of the security parameters ofthe selected packet data subconnection is used in protecting theembedded data, in other words in encryption and in forming acryptographic check sum). Also data compression possibly defined for theselected packet data subconnection is performed in block 204.

In block 205, the security protocol packet is sent to the selectedpacket data connection. It is clear to a skilled person that thetransport protocol entity 14 may manage the plurality of packet dataconnections of the transport protocol in a standard manner.

FIG. 2 b shows, as an example, a further block diagram of a securityprotocol entity in accordance with an embodiment of the presentinvention. In particular, FIG. 2 b shows features relating to receipt ofsecurity protocol packets from a transport protocol entity 24 in a node20. The transport protocol entity 24 forwards the security protocolpackets it receives in a known manner to the security protocol entity22. The security protocol entity 22 processes in block 211 a securityprotocol packet in accordance with the security parameters of the packetdata subconnection via which the security packet was received. In otherwords, the encryption/data integrity/compression and other processing isdone in accordance with security parameters stored in table 200. Inblock 212, the security protocol packet flow is restored using the orderinformation carried in the security protocol packets (if any). In block213, data to be forwarded to applications is extracted from the securityprotocol data packets. Typically this means forming of application datapackets or upper layer protocol packets. In block 214, data is forwardedto applications or other recipients.

It is appreciated that typically a security protocol entity containsfeatures relating to sending and receiving data, although in FIGS. 2 aand 2 b these features are shown separately for clarity reasons. It isalso appreciated that the order of functions may be different than shownin FIGS. 2 a and 2 b.

FIG. 3 a shows, as a first example, a partial flowchart relating toselection of packet data subconnections. Data to be sent in a securemanner is received in step 311. The packet data subconnection isselected in step 312 using Round-Robin algorithm. In other words, eachsubconnection is used in turn and for a specific security protocolpacket a next packet data subconnection is selected.

FIG. 3 b shows, as a second example, a partial flowchart relating to analternative selection of packet data subconnections. In this example,the packet data subconnection is selected in step 313 based on theapplication from where the data originates. If the security protocol isused for tunneling packet data connections, the security protocol maydetermine the application, for example, based on the port number of thepacket data connection to be tunneled. If the security protocol supportsa number of channels within the security protocol connection, the packetdata subconnections may be selected based on channels. For example,there may be a packet data subconnection (or a group of packet datasubconnections with identical security parameters) for each channel.

FIG. 3 c shows, as a third example, a partial flowchart relating to afurther alternative selection of packet data subconnections. In thisexample, the type of data to be transmitted securely in determined instep 314. A packet data subconnection is then selected in step 315 basedon the data type. Some examples of data characteristics based on whichpacket data subconnections can be selected are discussed below inconnection with embodiments of the invention relating to the SecureShell protocol. The examples are applicable also in connection withother security protocols. It is possible that in step 315 a packet datasubconnection is selected from a group of packet data subconnectionsbased, for example, on the Round-Robin algorithms or on thecharacteristics of the packet data subconnections.

It is clear to a skilled person that the features shown in FIGS. 3 a to3 c can be combined in a variety of ways. Some examples have beenmentioned above.

FIG. 4 shows, as an example, a flowchart of a method 400 for -setting upa security protocol session in accordance with an embodiment of theinvention. In step 401, a first packet data connection is establishedwith a remote node. The packet data connection may be a connection ofany reliable transport protocol, for example, a TCP connection. In step402, an authentication procedure is performed with the remote node viathe first packet data connection for establishing a security protocolsession. This authentication procedure typically provides mutualauthentication between the nodes. Various authentication schemes may beemployed, either alone or in combination. For example, achallenge-response scheme and/or a token-based authentication may beused.

In step 403, at least one security parameter is negotiated with theremote node for transmitting data through the first packet dataconnection. Typically at least some shared secret (session key) isformed in this negotiation for encrypting data and/or providingtamperproof integrity checksums. It is possible to negotiate thealgorithms used for encryption and/or integrity checks. In addition tocryptographic parameters, it is possible to negotiate furtherparameters. For example, it is possible to negotiate whether data to betransmitted is compressed and using which algorithm. A wholecryptographic context (algorithms and keys) for the first packet dataconnection may be negotiated in step 403.

In step 404, the nodes negotiate use of at least two packet datasubconnections for the security protocol session. In other words, instep 404 the use of packet data subconnections is negotiated. Step 404may be optional, especially if the nodes already beforehand know thatthe other node supports use of packet data subconnections for thesecurity protocol connection. The negotiation may be carried out usingmessages of the security protocol, or it may be carried out inout-of-band fashion. In its simplest form the negotiation may be onenode indicating support for use of packet data subconnections for thesecurity protocol session and the other node proceeding to step 405 inresponse to this indication. In step 405, the node negotiates at leastone security parameter with the remote node for a second packet dataconnection. In step 406, the second packet data connection isestablished with the remote node.

In step 407, the first and second packet data connections are handled aspacket data subconnections of the security protocol session. This meansthat data to be transmitted in the security protocol session istransmitted using a plurality of packet data subconnections instead of asingle packet data connection. Various proposals for selecting packetdata subconnections for security protocol packets are discussed above.

In addition to the two packet data subconnections, further packet datasubconnections may be established between the node and the remote nodefor transmitting security protocol packets of the security protocolsession.

It is appreciated that the order of the steps in FIG. 4 is an example,and the steps may be performed in a slightly different order orinterleaved with each other. For example, the negotiation of the use ofpacket data subconnections (step 404) and the negotiation of the atleast one security parameter for the first packet data connection (step403) may be interleaved. It is possible that the negotiation step 404 isrepeated for each further packet data subconnection. Alternatively, thenegotiation in step 404 may be carried out once and thereafter steps 405and 406 may be performed for each packet data subconnection onward fromthe second packet data subconnection.

In the following, a specific embodiment relating to the Secure Shell andTCP is discussed in more detail. It is appreciated that any featuresdiscussed in connection with this specific embodiment are applicablealso in connection with the more general discussion above.

The Secure Shell is a security protocol that can be used to securelytransmit data. Some specific examples of the use of Secure Shell aresecure file transfers and tunneling arbitrary TCP connections over asingle encrypted Secure Shell session.

It is possible to transmit information relating to many data channelsover one Secure Shell protocol session. For example, the data channelsmay relate to connections between various applications run in theendpoints of the Secure Shell protocol session. New data channels may beopened and existing data channels may be closed during the course of theSecure Shell protocol session. It is appreciated that the presentinvention is applicable to a Secure Shell session using a plurality ofchannels or using only one channel. The channels can be mapped on theTCP subconnections in a variety of ways. In principle, any number of TCPsubconnections can be used to transmit data relating to a given channeland a given TCP subconnection may carry information relating to anynumber of channels.

When the Secure Shell protocol is used between two endpoints, a TCPconnection is first set up between the endpoints for initial keyexchange (compare step 401 in FIG. 4). The endpoints authenticate eachother after the initial key exchange (step 402), and thereafter any datapacket transfer between the endpoints may be encrypted using a sessionkey. In accordance with the present invention, at least two TCPsubconnections are established for transmitting data over the SecureShell session. Each of these TCP subconnections has its securityparameters, and security parameters (keys and/or algorithms) of the TCPsubconnections may be changed by performing a key exchange relating to aspecific TCP subconnection during the Secure Shell session. The keyexchange messages need to be associated with the TCP subconnection towhich they relate. In the Secure Shell protocol, the key exchangemessages are typically sent using the TCP subconnection to which theyrelate. In general, the key exchange messages may explicitly indicatethe relevant TCP subconnection, in which case they need not be sentusing the TCP subconnection whose keying information they carry. Theplurality of TCP subconnections relating to a Secure Shell session shareauthentication and server identification performed when the Secure Shellsession is initially being set up.

In connection with the Secure Shell, the client typically initiates setup of the TCP subconnections (steps 401, 406). The client also typicallyinitiates the negotiations in step 404. On a general level, however, theflowchart in FIG. 4 shows the steps carried out by the Secure Shellserver or the Secure Shell client.

It is possible to route part of the TCP subconnections relating to oneSecure Shell session via different routes between the nodes. Forexample, each node may have more than one IP address and the IPaddresses may relate to different service providers. This way the effectof temporary overload situation in one of the service providers'networks is reduced. Also the load of the network interface may beshared.

Some examples of selecting a TCP subconnection for a Secure Shellprotocol packet are the following. It is possible to use all set-up TCPsubconnections in turns. As a more refined method, it is possible tojump over blocked TCP subconnections and this way to load evenly otherTCP subconnection except the slowest TCP subconnections. Some channelswithin the Secure Shell session or some applications may be tagged sothat data from these channels/applications is transmitted using a TCPsubconnection having a specific security properties (for example, aspecific encryption algorithm and a specific integrity check algorithm).This way data from different applications can transmitted using securityparameters suitable for each application. For example, a video streammay be encrypted with a light encryption algorithm whereas data filesmaybe first compressed and then secured using strong encryption and dataintegrity check algorithms. This way no excessive delays are caused forthe video stream and the file transfer is secured properly within asingle Secure Shell session.

A further example is to monitor the data to be sent (for example,monitor channels within the Secure Shell session) and determine the TCPsubconnection for the data based on properties of the data. If the datais compressible, it can be transmitted using a TCP subconnection wherethe compression is in use. It is possible, for example, to monitor datawithin channels and tag the channels accordingly. Then all data relatingto a channel is transmitted using a TCP subconnection (or a group of TCPsubconnections) having security parameters in accordance with the taginformation of the channel.

In the following it is discussed how the Secure Shell protocol can bemodified to support use of multiple TCP subconnections for one SecureShell session. The Secure Shell protocol has no explicit mechanism forprotocol extensions. In general, a protocol extension mechanism shouldbe backward compatible. For example, if one of the nodes tries to use anextension mechanism, there should be no error situation if the othernode does not support the protocol extension mechanism. Furthermore, ifboth nodes support the extension mechanism but not the same protocolextensions, the protocol connection should continue even if one nodeproposes a protocol extension the other node does not support. Aprotocol extension mechanism should provide a possibility to changebasic functionalities of the protocol, for example, packet format. Itshould also be possible to request various protocol extensions one byone and then start using those protocol extensions supported by bothnodes at a same time.

One solution for the protocol extension mechanism for the Secure Shellprotocol is to use the key exchange mechanism, which can be initiated atany time during the Secure Shell session—except when there is already akey exchange going on. The protocol extension mechanism is implementedas a new key exchange algorithm. This new key exchange algorithm doesnot in fact generate new entropy for shared secrets, but transforms oldsecrets into new form. In other words, the new key exchange algorithmgenerates new session keys based on information exchanged earlier (forexample, based on previous session keys), typically using part of thenonce information provided in the key exchange. After the new keyexchange has been carried out, the new session keys will be taken intouse together with those protocol extensions that were agreed upon.

In the following, the protocol extension mechanism for the Secure Shellprotocol is discussed in more detail in connection with FIG. 5. The newkey exchange algorithm (protocol extension mechanism) is indicated inthe following by ext1 by way of an example.

In step 501, the client initiates the protocol extension mechanism byinitiating a key exchange message sequence. The key exchange messagesequence is initiated by sending a KEXINIT packet with ext1 as the firstproposed key exchange method. In step 502, the server responds with aKEXINIT packet that has ext1 in its supported key exchange algorithms.As the client proposed ext1 and the server acknowledged support forext1, ext1 is selected as the key exchange algorithm. The KEXINITpackets contain also information about supported encryption and/orintegrity check algorithms. The nodes determine which encryption and/orintegrity check algorithms will be used based on the KEXINIT packets.

If the client initiated the exchange, it typically has at least onecommand to send to the server in step 503. If the client has no commandsto send, the method continues is step 507. In step 504, the client sendsa COMMAND packet that performs some action in the server side. Thespecific structure of the command packet is defined, for example, in theIETF documentation relating to the Secure Shell protocol. The commandactually does not take effect before entire key exchange is over andNEWKEYS packets are exchanged. In step 505, the server replies with aSTATUS packet that contains information whether the command wassuccessful or not. The STATUS packet contains also a possible reason forfailure (for example, command not supported by the server) and can alsoinclude some command specific data. In step 506 it is checked whetherthe client still has one or more commands to send. If yes, the methodreturns to step 504. Otherwise, the client sends an END_OF_CMDS packetin step 507.

If the server has no commands to send, the client receives anEND_OF_CMDS packet in step 508 and the method proceeds to step 511. Theserver may send a COMMAND packet that performs some action in the clientside. In FIG. 5, the command is shown to be executed in step 509. It is,however appreciated that the command actually does not take effectbefore entire key exchange is over and NEWKEYS packets are exchanged.The client replies to a COMMAND packet with a STATUS packet in step 510.The STATUS packet contains information whether the command wassuccessful or not. Furthermore, the STATUS packet contains a possiblereason for failure and can also include some command specific data.

As the server may still have one or more commands to send, the methodreturns to step 508. When the server sends the END_OF_CMDS packet, themethod continues in step 511. In steps 511 and 512, both the server andthe client send NEWKEYS packets. Immediately after this packet, allchanges made by (successful) commands during the key exchange takeeffect in step 513. New shared secret and key exchange hash is derivedfrom the old secret and key exchange nonce (information contained in thekey exchange initialization KEXINIT packets). New security algorithmsand compression settings are taken into use according to algorithm listsin KEXINIT packets.

The key exchange negotiation is identical in the case where the serverinitiates the exchange. Roles are unchanged; the client always sends itscommands first.

Since either side may choose not to send any commands during the ext1session, the shortest possible ext1 exchange is as follows. Both sidessend KEXINIT packets. The client sends END_OF_CMDS packet. The serversends END_OF_CMDS packet. Both sides send NEWKEYS packet. This simplekey exchange can be used in renegotiation of security parameters, suchas encryption and integrity check algorithms and compression method.

There is a slight difficulty that arises from the algorithm selectionlogic of the Security Shell protocol when the server side is theinitiator of the ext1 key exchange mechanism (protocol extensionmechanism). The first algorithm in the list of the supported algorithmsof the client is always selected. The client cannot always put ext1first to its list, as this would make generation of a new key for analready selected algorithm (in other words, rekey) impossible becauseext1 would always get selected.

Therefore clients and servers supporting ext1 may implement thefollowing logic. If the client is initiating a normal key exchange(initial or rekey), it adds ext1 as the last of its supported keyexchange mechanisms. On the other hand, if the client is initiating anext1 key exchange, it adds ext1 as the first of its supported keyexchange mechanisms. Similarly, if the server is initiating a normal keyexchange (initial or rekey), it adds ext1 as the last of its supportedkey exchange mechanisms. If the server is initiating an ext1 keyexchange, it adds ext1 as the first of its supported key exchangemechanisms.

If the client receives a KEXINIT message with ext1 as the firstsupported key exchange message it should reply with a KEXINIT messagewith ext1 as the first supported key exchange mechanism. If the clientreceives a KEXINIT message with ext1 as the first supported key exchangemechanism but has already sent its own KEXINIT where ext1 is not thefirst on the supported algorithms list, the key exchange is selectedaccording to the normal algorithm selection logic and when the selectedkey exchange algorithm is completed, the server can try to initiate ext1exchange again.

It is appreciated that no special attention needs to be directed to thecase where both sides are initiating ext1 exchange simultaneously. Thissimply leads to the situation where both sides have commands to sendduring the ext1 exchange and this is acceptable.

The Secure Shell protocol extension mechanism discussed above isbackward compatible. Should the other endpoint of the Secure Shellsession not support the protocol extension mechanism, the client andserver simply perform a key exchange. In a case where both the clientand server support the protocol extension mechanism but one of themfails to support the transport distribution (or any other command sentduring the protocol extension mechanism), the response to theunsupported command is an error message indicating that command isunsupported. The protocol extension mechanism terminates properly afterthe error message, as such error messages can occur during the keyexchange. It is appreciated that in general a failure in the keyexchange causes the Secure Shell session to be disconnected.

FIG. 6 shows, as an example, a flowchart of a method 600 for providingdistributed transport for the Secure Shell protocol in accordance withan embodiment of the invention. Negotiations relating to the use of TCPsubconnections for a Secure Shell session are performed using theprotocol extension mechanism shown in FIG. 5. In step 601, a first TCPconnection is established between the client and the server for theSecure Shell protocol. In step 602, the client and server nodes performmutual authentication and initial key exchange in accordance with theknown Secure Shell procedure. After step 602, the security algorithmsand key agreed in step 602 are used for the first TCP connection. When aSecure Shell session using one TCP connection has been established instep 601 and 602, it is possible to open TCP subconnections for theSecure Shell session in the following way at any time during the SecureShell session.

Negotiation about transport distribution for the Secure Shell sessionor—in other words—negotiation about the use of multiple TCPsubconnections for the Secure Shell session is carried out in step 603using the protocol extension mechanism shown in FIG. 5. The clientinitiates the protocol extension mechanism by placing ext1 as the firstkey exchange algorithm in the KEXINIT packet (see step 501).Alternatively, the server may initiate the protocol extension mechanism.In the following example, it is assumed that the client is theinitiator, as the client typically can better decide whether to try touse TCP subconnections and how many TCP subconnections to use. Theclient then sends a command to add sequence numbers or other orderinformation to the Secure Shell protocol packets (step 504), if theSecure Shell protocol packets do not already contain order information.The server responds with an OK status message (step 505). Thereafter theclient sends a command indicating use of TCP subconnections is inconnection with this Secure Shell connection (step 504). As a particularexample, the command may be called a transport-distribution-initcommand. The server responds with a status message, which may containsome information. Thereafter the client and the server calculate sharedsecret data for use in securing the data to be transmitted using thealready established first TCP connection. The protocol extensionmechanism of step 603 is finished with the NEWKEYS messages (steps 511,512). After the protocol extension mechanism, data transfer over thefirst TCP connection continues using the security algorithms and keysnegotiated in connection with the protocol extension mechanism.

It is appreciated that the protocol extension mechanism for the SecureShell protocol in step 603 provides one specific example of step 404. Instep 603, security algorithms and security keys for the alreadyestablished first TCP connection are additionally negotiated, asexplained above. The security algorithms negotiated in step 603 may bethe same as used before step 603, but keys typically change as a resultof step 603. It is possible that a security protocol supports a protocolextension mechanism, where new security algorithms and/or keys are notgenerated for the existing packet data connection.

If it turns out during step 603 that the other node does not supporttransport distribution, the Secure Shell session typically continueswith the already established TCP connection. Steps 604 and 605 in FIG. 6show this option. In step 605, the security algorithms and keynegotiated in step 603 are used for the single TCP connection.

When the negotiation about the use of the distributed transportmechanisms has been successful, a further TCP connection is establishedin step 606. Typically the client initiates the TCP connections for theSecure Shell protocol. Once the TCP connection has been established, theclient and server use the protocol extension mechanism discussed inconnection with FIG. 5 for negotiating security algorithms and keys forthe new TCP connection in step 607. In general, this is the only casewhere the ext1 type key exchange can be performed as the first keyexchange for a TCP connection. Step 607 is carried out using the TCPconnection established in step 606, and thus the client and server andassociate the TCP connection and the Secure Shell protocol packetsrelating to the key exchange. During the protocol extension mechanism instep 607 typically the client requests explicit ordering information tothe Secure Shell packets (step 504) and sends a command that this newTCP connection is to be used together with at least one already existingTCP connection as TCP subconnections for the Secure Shell sessionbetween the nodes (step 504). This command may be called, for example, atransport-distribution-execute command.

When the protocol extension mechanism in step 607 terminates, the newTCP connection does not any more serve a new Secure Protocol sessionbetween the nodes. The new TCP connection is one of multiple TCPsubconnections serving a single Secure Shell Session between the nodes.Security algorithms and keys negotiated in step 607 are used for the newTCP connection in step 608, where the Security Shell session continuesusing multiple TCP subconnections. It is appreciated that when using theSecure Shell protocol extension mechanism, the keys for the new TCPconnection depend also on information relating to the previous keyexchange in the Secure Shell session (that is, on either a normal keyexchange or on a protocol extension mechanism).

If more than one further TCP subconnection is to be established eitherin the beginning of the Secure Shell session or later on during thesession (step 609), the protocol extension mechanism is used in step 610to initiate the establishment of a further TCP subconnection for thedistributed transport. Step 609 may be carried out using any of thealready existing TCP subconnection relating to this Secure Shellsession. This is because each of the multiple TCP subconnections has asimilar role in the Secure Shell distributed transport mechanism.Thereafter steps 606 to 608 are performed, as shown in FIG. 6.

Alternatively, it is possible that more than onetransport-distribution-init command is sent in step 603. Onetransport-distribution-init command is sent for each new TCPsubconnection. In this case, steps 606 to 608 are repeated once for eachnew TCP subconnection.

As a further alternative, it may be possible that in the negotiation instep 603, the number of new TCP connections is indicated as a parameterin a command, for example, in the transport-distribution-init command.

It is appreciated that if, for some reason, a new TCP connection wouldnot be established after step 603 or 610, the Secure Shell sessiontypically continues using the existing single TCP connection or theexisting at least two TCP subconnections for the distributed transport.

Referring to FIGS. 4 and 6, it is appreciated that step 603 alone orsteps 603 and 610 in combination can be considered as a specific exampleof step 404. Step 607 provides an example of step 405. As mentionedabove, the order of steps may vary. As an example, consider thefollowing. In FIG. 4, it is explained by way of example that securityparameters for a new packet data connection are negotiated in step 405before the second packet data connection is initiated in step 406. InFIG. 6, the second packet data connection is established in step 606 andsecurity algorithms and keys are negotiated in step 607 using thealready established packet data connection.

If a given TCP subconnection of a Secure Shell session needs to beterminated, this can be done in the following way during the SecureShell session. The following information is sent over the TCPsubconnection to be terminated. The client initiates the protocolextension mechanism with a KEXINIT message (step 501). Later on duringthe protocol extension mechanism, the client sends a command toterminate the TCP subconnection (step 504), and the server responds withan OK status message (step 505). The protocol extension mechanism isended (steps 511, 512) and the TCP subconnection is terminated. The lastSecure Shell protocol packets for each direction are typically theNEWKEYS packets. The Secure Shell protocol session continues using theremaining TCP subconnections or a single TCP connection.

It is appreciated that in this description the term “node” refers to anydevice capable of setting up packet data connections and transmittingdata using the packet data connection and a security protocol. The terms“client” and “server” refer to the client/server roles of nodes.Embodiments of the present invention are typically implemented ascomputer programs.

Some specific examples of nodes where the present invention isapplicable are the following. Firstly, a node may be an edge networknode handling securing of virtual private network connections over apublic data network. Secondly, a node may be any network node that needsto secure data to be transmitted or received. Thirdly, a node may be aportable communications device.

A system in accordance with an embodiment of the invention is typicallya data processing system, which may include a number of computingdevices. The system may be, for example, a server cluster supportingcommunications using a security protocol. A device in accordance with anembodiment of the invention is typically a computer or other computingdevice, for example, a server supporting communications using a securityprotocol.

It is appreciated that embodiments of the invention may be implementedusing software running on a general purpose computing device, usingdedicated hardware, or using a suitable combination of software anddedicated hardware. It is appreciated that a computer program inaccordance with an embodiment of the invention may be embodied on arecord medium, stored in a computer memory or carried on an electricalcarrier signal. A computer program product in accordance with anembodiment of the invention may be embodied on a computer readablerecord medium.

Although preferred embodiments of the apparatus and method embodying thepresent invention have been illustrated in the accompanying drawings anddescribed in the foregoing detailed description, it will be understoodthat the invention is not limited to the embodiments disclosed, but iscapable of numerous rearrangements, modifications and substitutionswithout departing from the spirit of the invention as set forth anddefined by the following claims.

1. A method for transmitting packet data over a network with a securityprotocol, the method comprising: establishing a first packet dataconnection to a remote node, performing an authentication procedure withthe remote node via the first packet data connection for establishing asecurity protocol session with the remote node, negotiating at least onesecurity parameter with the remote node for transmitting packets throughthe first packet data connection, establishing a second packet dataconnection to the remote node, negotiating at least one securityparameter with the remote node for use with the second packet dataconnection, and handling the first and second packet data connections aspacket data subconnections associated with the security protocolsession.
 2. The method as defined in claim 1, comprising negotiating useof packet data subconnections for the security protocol.
 3. The methodas defined in claim 2, comprising negotiating use of each one packetdata subconnection separately.
 4. The method as defined in claim 2,wherein a protocol extension mechanism of the security protocol is usedfor negotiating use of packet data subconnections for the securityprotocol.
 5. The method as defined in claim 1, comprising negotiatingthe at least one security parameter for use with the second packet dataconnection using the second packet data connection.
 6. The method asdefined in claim 1, comprising: transmitting at least one securityprotocol packet through the first packet data connection, andtransmitting at least one security protocol packet through the secondpacket data connection.
 7. The method as defined in claim 1, comprisingincluding order information to each security protocol packet beforetransmission through a packet data subconnection.
 8. The method asdefined in claim 1, wherein said at least one security parametercomprises at least one of an encryption algorithm, a key for anencryption algorithm, an integrity check algorithms, and a key for anintegrity check algorithm.
 9. The method as defined in claim 1,comprising negotiation of at least one further parameter for a packetdata connection.
 10. The method as defined in claim 9, wherein said atleast one further parameter comprises a data compression mode parameter.11. The method as defined in claim 1, wherein the security protocol isthe Secure Shell protocol.
 12. The method as defined in claim 1, whereinthe first and second packet data connections are Transfer ControlProtocol connections.
 13. The method as defined in claim 1, comprisingselecting a packet data subconnection for transmitting a securityprotocol packet.
 14. The method as defined in claim 13, whereinselection is based at least on properties of the security protocolpacket.
 15. The method as defined in claim 14, wherein the properties ofthe security protocol packet comprise at least one of type of datacarried in the security protocol packet and cryptographic strength ofsecurity desired for the data carried in the security protocol packet.16. The method as defined in claim 13, wherein selection is based atleast on properties of the packet data subconnections.
 17. The method asdefined in claim 16, wherein the properties of the packet datasubconnections comprise at least one of transport properties of a packetdata subconnection and cryptographic strength of security provided bythe security parameters of a packet data subconnection.
 18. The methodas defined in claim 1, comprising: determining a characteristic of apacket data stream transmitted within the security protocol session, andselecting a packet data subconnection for transmitting the packet datastream based on the determined characteristic of the packet data stream.19. The method as defined in claim 18, wherein the characteristic is atleast one of: level of compressibility of the packet data stream,cryptographic strength of encryption desired for the packet data stream,cryptographic strength of data integrity checking desired for the packetdata stream.
 20. The method as defined in claim 1, comprisingdetermining a characteristic for at least two packet datasubconnections, and selecting a packet data subconnection fortransmitting a security protocol packet at least partly on the basis ofthe characteristics of the at least two packet data subconnections. 21.The method as defined in claim 1, comprising selecting packet datasubconnections in turn for data to be transmitted with the securityprotocol.
 22. A communication system comprising: means for establishinga first packet data connection to a remote node, means for performing anauthentication procedure with the remote node via the first packet dataconnection for establishing a security protocol session, means fornegotiating at least one security parameter with the remote node fortransmitting packets through the first packet data connection, means forestablishing a second packet data connection to the remote node, meansfor negotiating at least one security parameter with the remote node foruse with the second packet data connection, and means for handling thefirst and second packet data connections as packet data subconnectionsof the security protocol session.
 23. A device for a communicationssystem comprising: means for establishing a first packet data connectionto a remote node, means for performing an authentication procedure withthe remote node via the first packet data connection for establishing asecurity protocol session, means for negotiating at least one securityparameter with the remote node for transmitting packets through thefirst packet data connection, means for establishing a second packetdata connection to the remote node, means for negotiating at least onesecurity parameter with the remote node for use with the second packetdata connection, and means for handling the first and second packet dataconnections as packet data subconnections of the security protocolsession.
 24. The device as defined in claim 23, comprising a networknode.
 25. The device as defined in claim 23, comprising a portablecommunications device.
 26. The device as defined in claim 23, comprisingan edge node for a virtual private network.
 27. A computer programembedded on a computer-readable medium comprising program codeconfigured to execute: performing an authentication procedure with theremote node via a first packet data connection for establishing asecurity protocol session with the remote node, negotiating at least onesecurity parameter with the remote node for transmitting packets throughthe first packet data connection, negotiating at least one securityparameter with the remote node for use with a second packet dataconnection, and handling the first and second packet data connections aspacket data subconnections associated with the security protocolsession.
 28. A system configured to: establish a first packet dataconnection to a remote node, perform an authentication procedure withthe remote node via the first packet data connection for establishing asecurity protocol session, negotiate at least one security parameterwith the remote node for transmitting packets through the first packetdata connection, establish a second packet data connection to the remotenode, negotiate at least one security parameter with the remote node foruse with the second packet data connection, and handle the first andsecond packet data connections as packet data subconnections of thesecurity protocol session.
 29. A device configured to: establish a firstpacket data connection to a remote node, perform an authenticationprocedure with the remote node via the first packet data connection forestablishing a security protocol session, negotiate at least onesecurity parameter with the remote node for transmitting packets throughthe first packet data connection, establish a second packet dataconnection to the remote node, negotiate at least one security parameterwith the remote node for use with the second packet data connection, andhandle the first and second packet data connections as packet datasubconnections of the security protocol session.